In computing, a shatter attack is a programming technique employed by crackers on Microsoft Windows operating systems that can be used to bypass security restrictions between processes in a session. A shatter attack takes advantage of a design flaw in Windows's message-passing system whereby arbitrary code could be injected into any other running application or service in the same session, that makes use of a message loop. This could result in a privilege escalation exploit.[1]
Shatter attacks became a topic of intense conversation in the security community in August 2002 after the publication of Chris Paget's paper titled, "Exploiting design flaws in the Win32 API for privilege escalation".[2] The paper, which coined the term "shatter attack", explained the process by which an application could execute arbitrary code in another application. This could occur because Windows allows unprivileged applications to send messages to message loops of higher-privileged application - and some messages can have the address of a callback function in the application's address space as its parameter. If an attacker manages to put his own string into the memory of the higher-privileged application (say by pasting shellcode to an edit box or using VirtualAllocEx and WriteProcessMemory) at a known location, they could then send WM_TIMER messages with callback function parameters set to point to the attacker's string.
A few weeks after the publication of this paper, Microsoft responded, noting that: "The paper is correct that this situation exists, and it does correctly describe its effect. ... Where the paper errs is in claiming that this is a flaw in Windows. In reality, the flaw lies in the specific, highly privileged service. By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there."[3]
In December 2002, Microsoft issued a patch for Windows NT 4.0, Windows 2000, and Windows XP that closed off some avenues of exploitation.[4] This was only a partial solution, however, as the fix was limited to services included with Windows that could be exploited using this technique; the underlying design flaw still existed and could still be used to target other applications or third-party services.[5] With Windows Vista, Microsoft aimed to solve the problem in two ways: First, local users no longer log in to Session 0, thus separating the message loop of a logged-in user's session from high-privilege system services, which are loaded into Session 0. Second, a new feature called User Interface Privilege Isolation (UIPI) was introduced, whereby processes can be further protected against shatter attacks by assigning an Integrity Level to each process.[6] Attempts to send messages to a process with a higher Integrity Level will fail, even if both processes are owned by the same user. However, not all interactions between processes at different Integrity Levels are prevented by UIPI.[6] Internet Explorer 7, for example, uses the UIPI feature to limit the extent to which its rendering components interact with the rest of the system.
The way sessions are instantiated was redesigned in Windows Vista and Windows Server 2008 to provide additional protection against shatter attacks. Local user logins were moved from Session 0 to Session 1, thus separating the user's processes from system services that could be vulnerable.[7][8]
This creates backward compatibility issues, however, as some software was designed with the assumption that the service is running in the same session as the logged-in user. To support this view, Windows Vista and Windows Server 2008 include a Windows service called "Interactive Services Detection" that enables access to dialogs created by interactive services when they appear. The interactive user is shown a dialog box and is offered the ability to switch to Session 0 to access the dialog box.[9]
Also, services configured with the "interact with the desktop" privilege can still create popup dialogues, system notification icons, or other user interface elements for the interactive user. This circumvents the protections afforded by having the interactive user logged in to a separate session, so this practice is discouraged. Instead, a two-process design is recommended where a process is loaded into the user's session that interacts with the service process through inter-process communication. Additionally, when a privileged operation is required to be undertaken, an authenticated call is made that loads additional service code. Once that privileged code is finished doing what needs to be done, it is unloaded from memory so that it does not remain to be a possible target for later exploitation.